The use of personal communication devices in various aspects of our daily lives has increased dramatically over recent years. Modern mobile telephones are becoming multipurpose devices capable of various new security applications, such as banking and digital rights management (DRM) clients. With the proliferation of personal communication devices, it has become more and more important to protect the critical data stored within the device. For example, the use of a PIN has been implemented with personal communication devices to control access to the device. However, it is possible that one may guess the PIN if given an unlimited number of time and attempts to enter a PIN. Thus, in addition to the use of a PIN, it is useful to limit the number of attempts to enter a PIN.
In order to limit the number of attempts to access the device, it is possible to use some type of counter in the personal communication device. The counter is cryptographically bound to state information related to the critical data used by the device and may be used as a theft-protection mechanism. In this context, the state information may mean information indicating the number of successive incorrect PIN access attempts. After a certain number (say three) of incorrect PIN entry attempts, the device locks up until a special PIN unblocking key (i.e., PUK code) is entered.
If the state information storage on the device lacks integrity-protection, it may be possible for an attacker to record the current state information, try three successive PINs (during which the device will update the state information), and overwrite the newly updated state information with the old recorded data. In this way, the attacker would get three more tries to find the correct PIN.
In addition to keeping track of successive incorrect password/PIN access attempts, there are various other uses in the area of DRM, in which the ability to securely store state information in a secure personal device may be needed.
Keeping track of a counter value can be useful also when controlling the consumption of data content is needed. For example, a third party might want to prevent a user of a personal communication device from playing a song more than ten times. The right to play the song ten times is delivered as an electronic voucher that specifies a 10-use restriction by implementing a counter. However, if a user can reset the counter after each use, the song can be played indefinitely without having to pay the owner of the data for each use.
In mobile devices, there are also device dependant security states which should be reliably accessible throughout the life time of the device. For instance, a mobile telephone may have a phone lock feature that effectively should prevent use of stolen phones. When the lock is engaged, an identifier of the present subscriber identity module (SIM) is stored in a rewriteable persistent memory of the phone with a suitable representation (for instance, a one-way hash-code) of a matching passcode. Whenever the SIM is replaced, if the phone protection is enabled, the phone first asks the user for the corresponding passcode and only if successfully entered, the phone stores the ID of the new SIM and allows its use. However, to prevent brute force attack, the phone should also maintain a counter of failed passcodes so that after three failed attempts, the phone becomes more thoroughly locked.
In the area of DRM, where non-volatile maintenance of critical state information has been needed, various methods of cryptography have been used to protect the critical state information, such as critical counter values, etc.
One aspect of cryptography involves the encoding or encrypting of digital data to render it incomprehensible by all but the intended recipients. In other words, when cryptography is employed in the context of DRM, the data is encrypted and a decryption key is delivered to those terminals or users that have paid to consume the data content. To this end, cryptographic systems can be used to preserve the privacy and integrity of the data by preventing the use and alteration of data by unauthorized parties. In addition to encryption, also authentication of the origin of the data is used in order to make sure that e.g., only a party who has the right key can generate the right signature or message authentication code (MAC).
For example, a plaintext message consisting of digitized sounds, letters and/or numbers can be encoded numerically and then encrypted using a complex mathematical algorithm that transforms the encoded message based on a given set of numbers or digits, also known as a cipher key. The cipher key is a sequence of data bits that may either be randomly chosen or have special mathematical properties, depending on the algorithm or cryptosystem used. Sophisticated cryptographic algorithms implemented on computers can transform and manipulate numbers that are hundreds or thousands of bits in length and can resist any known method of unauthorized decryption. There are two basic classes of cryptographic algorithms: symmetric key algorithms and asymmetric key algorithms.
Symmetric key algorithms use an identical cipher key for both encrypting by the sender of the communication and decrypting by the receiver of the communication. Symmetric key cryptosystems are built on the mutual trust of the two parties sharing the cipher key to use the cryptosystem to protect against distrusted third parties. A well-known symmetric key algorithm is the National Data Encryption Standard (DES) algorithm first published by the National Institute of Standards and Technology. See Federal Register, Mar. 17, 1975, Vol. 40, No. 52 and Aug. 1, 1975, Vol. 40, No. 149. The sending cryptographic device uses the DES algorithm to encrypt the message when loaded with the cipher key (a DES cipher key is 56 bits long) for that session of communication (the session key). The recipient cryptographic device uses an inverse of the DES algorithm to decrypt the encrypted message when loaded with the same cipher key as was used for encryption.
Asymmetric key algorithms use different cipher keys for encrypting and decrypting. In a cryptosystem using an asymmetric key algorithm, the user makes the encryption key public and keeps the decryption key private, and it is not feasible to derive the private decryption key from the public encryption key. Thus, anyone who knows the public key of a particular user could encrypt a message to that user, whereas only the user who is the owner of the Private key corresponding to that public key could decrypt the message. This public/private key system was first proposed in Diffie and Hellman, “New Directions in Cryptography,” IEEE Transactions on Information Theory, November 1976, and in U.S. Pat. No. 4,200,770 (Hellman et al.).
The Cryptographic systems noted above have been used to protect state information in a personal communication device by securely storing the state information in a couple of ways. First, by writing a snapshot to the state information and computing its “checksum,” e.g., by using a one-way hash function. The result is stored within a tamper-resistant memory location of the device. Therefore, if someone tries to change the state information, the checksum of the result will not match the checksum value stored within the personal device. Second, by using a monotonic, persistent counter within the device. Every time there is a state change, the state information is stored along with the current counter value encrypted using a device key. Thus, no one can change the encrypted state information without the key.
However, both of these prior-art methods require a small amount of read-write storage within the same tamper-resistant zone which contains the secure processor itself.
In the field of DRM, the involved applications are typically provided by digital integrated circuitry. If a secure processor running such applications has enough updatable space within its tamper-resistant persistent storage, it is rather easy to implement integrity protection for state information. Maheshwari et al. have disclosed such an arrangement in “How to Build a Trusted Database System on Untrusted Storage”, OSDI 2000. Unfortunately, the economical reasons are eradicating the non-volatile rewriteable memories on digital integrated circuitries. Having an updatable memory, or read-write storage, integrated within the secure processor's tamper-resistant perimeter is expensive, especially on particularly resource-constrained devices like mobile phones. In other words, the storing of state information and secure processing of applications is not always economical (or not even practical) within the same tamper-resistant zone as the secure processor, for example, within the secure processor's integrated circuitry.
Furthermore, as is known in the art, the digital IC blocks tend to be cost optimised so that some of them even cannot accommodate a rewriteable persistent memory (e.g., flash memory), as inclusion of such would mandate manufacturing 6 silicon layers instead of the common 4 for the area of the IC block. Hence again, simply providing a secure processor with a non-volatile memory seems not economically and technically suitable for all uses.
Accordingly, there is a problem how to implement an integrity-protected secure storage for a secure processor of a generally resource-constrained device.
As a practical solution to this problem, a co-pending patent application of the applicants of the present application, publication number US 2003/0079122 A1, presents the idea of using an external tamper-resistant storage device to store important state information. The idea of authenticated (or “trusted”) counters is introduced. The patent application US 2003/0079122 A1 discloses that an authenticated counter can be implemented in an external tamper-resistant security token, such as a smartcard, which can be used by the secure processor to integrity-protect its state storage. To make this work, the secure processor needs to be able to authenticate the external security token. For this purpose, the patent application US 2003/0079122 A1 discloses using a public key infrastructure (PKI).
However, a public key infrastructure is rather complex to set up because it involves co-ordination and agreements between device manufacturers and manufacturers of external security tokens. It also imposes an amount of processing load onto the external security tokens or memories.